Gracefully handle ForeignUIDRange on systemd < 259#4214
Gracefully handle ForeignUIDRange on systemd < 259#4214gourryinverse wants to merge 1 commit intosystemd:mainfrom
Conversation
gourryinverse
force-pushed
the
foreign_uid
branch
from
3ed880a to
b7e41bc
Compare
There was a problem hiding this comment.
I'm curious about your use case? Booting from a directory without the foreign UID range is flat out impossible if you're running systemd as the payload in the container/VM (unless you're building as root I guess, then it could work and I agree we should probably keep supporting that, but I would insist on building as root in that case).
|
I had an existing workflow for development with claude building images with mkosi (and mkosi-kernel stubs), launching qemu with new udev services, and then probing the qemu instance for information. I need to use upstream mkosi to have flexibility with the qemu instance (things like adding numa nodes and other configurations that are hard-coded into qemu.py and configs). But I don't have flexbility to just change systemd packages as a whole. So this all worked for me until the recent ForeginUID changes, unless you're saying the current design was a hack that should never have been used. |
The foreign UID range support (mapForeign in nsresourced's AllocateUserRange) was added in systemd 259. On older systemd versions, building with ForeignUIDRange=yes fails because nsresourced does not understand the mapForeign parameter. Instead of failing, check the host systemd version at build time and skip the UID shift with a warning when systemd < 259. The VM can still boot, virtiofsd's --become-root makes files appear root-owned in the guest. Similarly, downgrade the QEMU launch check from die() to a warning so non-foreign directory images can still be booted, and teach virtiofsd to use --bind instead of --bind-foreign when the image isn't actually foreign-UID-owned. Signed-off-by: Gregory Price <gourry@gourry.net>
gourryinverse
force-pushed
the
foreign_uid
branch
from
b7e41bc to
11dc54a
Compare
were you building the image as root? |
|
Nope, just building as a user. Sounds like that should not have worked? |
So for qemu it did work before I guess because I assume you had /etc/subuid and /etc/subgid set up and configured properly? The issue is that your user only has access to a single uid and to run a full systemd system you need 64k. Before the nsresourced PR we solved that via /etc/subuid and /etc/subgid. Since that commit we use the systemd native way from systemd-nsresourced. Keeping the subuid stuff meant significant complexity so I dropped it. I wouldn't expect mkosi qemu to be able to boot directory images without the foreign UID range stuff now. Are you saying that works for you now with the changes in this PR? |
|
It continues to work with this change yes. It was working for me before as well. I wonder if there's some package version quirks going on here. |
2 participants
The foreign UID range support (mapForeign in nsresourced's AllocateUserRange) was added in systemd 259. On older systemd versions, building with ForeignUIDRange=yes fails because nsresourced does not understand the mapForeign parameter.
This breaks upstream mkosi when running on older systems, image building fails.
Instead of failing, check the host systemd version at build time and skip the UID shift with a warning when systemd < 259. The VM can still boot, virtiofsd's --become-root makes files appear root-owned in the guest.
Similarly, downgrade the QEMU launch check from die() to a warning so non-foreign directory images can still be booted, and teach virtiofsd to use --bind instead of --bind-foreign when the image isn't actually foreign-UID-owned.